Remarks and Arguments 

Claim Rejections based on 35 USC S 101 



The Office Action purports to reject claims 13-16 and 20-23 as not 
patentable subject matter pursuant to 35 USC §101. However, those 
claims were no longer a part of the instant application, since, in response 
to the initial Office Action on this application, dated June 14, 2005, 
imposing a restriction requirement. Applicant filed a response electing to 
pursue claims 1-9, and withdrawing claims 10-60 from consideration, 
without prejudice to their being pursued in a divisional application at a 
later date. This response affirms the withdrawal from consideration of 
former claims 10-60, and a revised listing of claims reflecting this election 
is provided. 

Claim Rejections based on 35 USC S 102(e) 

L Claim 1 was rejected as being anticipated by Barbara, citing the 
Abstract, Fig 1, and paragraph 21. 

Applicant respectfiiUy suggests that the Office Action misapprehends the 
nature of the two very different inventions described by Barbara and by 
the instant application for a Persistent Dynamic Payment System 
(hereinafter "PDF' or "PDPS"). 

Barbara does describe a method for making on-line payments, but that is 
about as far as the similarities go. Like the other payment approaches 
mentioned in the PDP "background of the prior art" section (namely SET, 
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Rosen, and Linehan), Barbara involves a new method of online payment, 
which is incompatible with most current payment schemes, and does not, 
as does PDP, provide a cardholder with an improved means of payment 
over existing payment systems. 

As consistently specified by Barbara, a user attempts to make a purchase 
at an online merchant in the manner described in cited Paragraph 21 : 

"[0021] In the on-line payment method and system for an embodiment of 
the present invention, the user can use the funds residing in the transaction 
account, for example, for making on-line payments, on-line purchases, 
off-line purchases, cash withdrawals, credit card account payments, bill 
payments, and/or international payments with funds in the transaction 
account. For an on-line payment, for example, funds in the transaction 
account are designated for the online payment to a recipient according to 
an instruction by the user The user can make an on-line purchase, for 
example, by authorizing payment to an on-line merchant for an on-line 
transaction by furnishing the on-line merchant the transaction account 
number." 

Nothing in the also-cited Abstmct, or in Fig. 1, adds to the disclosure 
anything like the system described in PDP. 

Barbara specifies that the transaction account number follows a specific 
syntax: "[0059] The transaction account 30 for an embodiment of the 
present invention enables the recipient 14 to save or accumulate the 
money that is received. The transaction account 30 is a depositorv account 
subject to all of the rules and regulations of any bank account '' 

However, existing online merchants do not accept Barbara's transaction 
account number In Barbara, an online purchase or payment could only be 
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made at a merchant who has modified/customized their web site in 
advance to accept the "furnished transaction account number'' provided by 
the user, which is necessarily in an entirely different form from the format 
currently utilized for receipt by the merchants of credit card or debit card 
information. 

The existing standard process for making online merchant purchases is 
that the payer enters a credit card number, billing address, expiiy date, and 
the other information needed for authorization of a credit card transaction 
through the payment network. 

Barbara clearly distinguishes that the transaction account number is not a 
credit card number, and those with knowledge in the art know that the 
transaction accoimt, adhering to Barbara's specified deposit account 
standard, cannot be a credit card account. Credit card numbers follow a 
unique globally standard syntax which is different from bank deposit 
account numbers. (For example, all credit card numbers begin with a 
standard prefix - Visa is 4, MasterCard is 51 to 55, Discover is 601 1, etc.; 
debit card numbers follow the same syntax as credit cards, and are also 
different from deposit account numbers.) In addition, Barbara makes no 
reference to the other information that a xiser would be required to provide 
to the merchant to authorize a credit card transaction (billing address, 
expiry date, etc.). Given the existing standard process for authorizing 
online merchant purchases, a user of Barbara's service cannot furnish the 
transaction account to an online merchant and conduct an online purchase, 
without having made a prior arrangement with an online merchant to 
customize the site's design to accept the transaction account for payment. 

As discussed in PDP's section on the prior art, payment methods that, like 
Barbara, require participants to conform to a new protocol, are insufficient 
and cannot readily be widely adopted given the millions of existing online 
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merchants who are hesitant to change their sites. Even the most successful 
alternative payment process, PayPal, has less than 5% of the global 
eCommerce payment volume [Sources: Forrester Research / Shop.org 
(US); IDC (non-US)], One of the reasons PayPal hasn't been more widely 
adopted is that merchants are reluctant to change their shopping cart to 
accept entry of the user's email address, which is analogous to the way the 
user would furnish Barbara's transaction accoimt number. 

The challenge that PDP addresses is how to enable virtually any 
cardholder with browser access to the Internet to complete a purchase 
transaction with virtually any of the millions of global online merchants, 
without requiring the merchants to do anything differently from their 
current processes. Unlike Barbara, PDP is able to enhance the security 
and flexibility of the overall payment process without impacting the 
merchant's standard payment process, indeed without the change even 
being visible to the merchant 

As stated in the PDP Summary of Invention, "embodiment of the 
invention improve the existing methods and systems". On page 10, line 8- 
10, "It is important to note that the operation of the PDPS does not require 
participation of the merchant in anv wav beyond the normal process of 
submitting an authorization request to the acquiring bank." As stated on 
PDP page 23, line 29 to page 24, line 3, "The proxy account number has 
the standard syntax of a credit card number ... When a payer utilizing the 
PDPS goes shopping on the Internet, the proxy account number is entered 
when a credit card number is requested." PDP Claim 1 recites "in a 
method of making a payment from a payer to a merchant of the type where 
the payment involves the merchant accepting a proposed payment in the 
form of an account number having a standard syntax from a payer." 
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Thus, PDP differs in a fundamental way from Barbara, with its approach 
of requiring on-line merchants to adopt a new payment protocol For that 
reason alone, Barbara does not anticipate PDP claim 1. 

There are other important differences as well, however, which 
demonstrate that, contrary to what is stated in the Office Action, Barbara 
does not in fact anticipate claim 1 of PDP. 

Claim 1 covers: "a method of making a payment from a payer to a 
merchant of the type where the payment involves the merchant accepting a 
proposed payment in the form of an accoxmt number having a standard 
syntax from the payer at completion of a purchase, followed by the 
merchant requesting an authorization for the proposed payment from a 
financial institution, the improvement comprising the following act 
performed by a trusted third party service: 

a ) authenticating the payer and authorizing the proposed payment in a 
single integrated process conducted without the involvement of the 
merchant/' 

As will be shown, Barbara does not disclose PDP*s novel improvement of 
''authenticating the payer and authorizing the proposed payment in a single 
integrated process conducted without the involvement of the merchant" 

In Barbara, authentication and authorization are clearly two separate 
processes, not a single integrated process. In the prior art, authentication 
and authorization have always been done as two separate processes, and 
the same is true of Barbara; whereas PDP is distinguished by its ability to 
meld the formerly separate processes into a single integrated process. 

First, some background on the term "authorization." As stated on page 2 
of the PDP application, "Methods of conducting e-Commerce transactions 
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wherein a buyer (payer) pays for goods or services obtained from a 
merchant (recipient) with a credit card in an online transaction over a 
computer network, such as the Internet, are well known in the prior art. 
While there are variations, the usual process for making such a transaction 
is that the payer enters a credit card number, billing address, and other 
information needed for authorization of the payment onto a form on the 
web site to pay for an e-commerce transaction. The credit card number 
and the other information are transmitted over the Intemet from the payer 
to the web site, generally in an encrypted form such as Single Socket 
Layer ('SSL'). The merchant site translates the information into a 
standard inter-bank protocol and forwards the information to a financial 
institution, usually known as the merchant's Acquiring bank, with which 
the merchant has an existing relationship, generally over secure lines. The 
Acquiring bank forwards the transaction to the issuer of the credit card, 
generally known as the issuing bank, over a secure inter-bank payment 
network, based on routing information that is part of the credit card 
number. The issuing bank either approves or denies the proposed 
transaction and retums the decision to the merchant through the Acquiring 
bank." 

The above process is presented in PDP Figure 1, which shows that the 
purchase authorization process takes place between the merchant's back 
end system, the Acquiring bank, and the issuing bank. 

Comparing PDP Figure 2 with Barbara Figure 1 Weights the 
fiindamental difference between the two inventions. PDP Figure 2 shows 
that the interaction between the Acquiring and issuing banks takes place 
over a payment network, e£,. Visa's network. This is a private, secure 
network and is not accessible to the Intemet or to Intemet attached 
applications such as those described by Barbara. 
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Figure 1 of Barbara shows the Internet portion of the interaction between 
the recipient (merchant), the cardholder, and the third party that is 
partnered with a financial institution. The payment network itself is not 
shown. Most importantly, the interconnection between the recipient 
(merchant), and the fmancial institution is not shown. Barbara relies on 
the existing processes provided by the partner financial institution, which 
processes do not provide for authenticating and authorizing a purchase 
transaction in a single integrated process. 

Barbara clearly states that it relies on the existing processes provided by 
the partner financial institution: 

"[0105] An embodiment of the present invention touches several of the 
financial institution's systems, such as the financial institution's merchant 
business, which has a role as the facilitator of payments and in issuing 
bank credit cards. An embodiment of the present invention also leverages 
the financial institution ACH system as the facilitator and processor of 
ACH payments that customers choose to use for checking accounts. In 
addition, an embodiment of the present invention leverages, for example, a 
bank card operated accounting system of the financial institution, which is 
a card member transactions system, as well as the bank card's Internet 
system that fecilitates the Internet backend." 

"[0067] In addition, the merchant payments aspect for an embodiment of 
the present invention leverages the strength of the existing credit card 
business of the service providing financial institution 20" 

Not only does Barbara's infrastructure make it impossible to both 
authenticate and authorize in a single process, Barbara does not even 
mention the ability to perform the authorization process for a payment 
transaction. When the word "authorization" is mentioned in Barbara, it is 
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used in a completely different meaning of the word. One place it is used it 
relates to the process of performing initial registration of a user's credit 
card: 

"8. The method of claim 7, wherein receiving the information from the 
user about the credit card account further comprises performing a back 
end authorization to confirm that the information relates to a valid credit 
card account of the user." So, Barbara's back end "authorization" to 
validate a credit card account is entirely different from PDP claim 1, 
which covers the authorization process for a discrete payment transaction 
initiated by an on-line merchant. In a second use of the word 
authorization by Barbara, it is again not related to the process of obtaining 
authorization from a financial institution, but rather describes the process a 
user follows to give a pproval for a payment, for example: 

"29. The method of claim 1, wherein allowing the user to use the 
funds in the transaction account for making a credit card account payment 
further comprises allowinjg the user to authorize a payment to the user's 
credit card account with funds in the transaction account according to an 
instruction bv the user ." 

PDP Figures 3 and 4, by contrast, clearly show both the Internet network 
and the payment network, and how PDP performs the function which is its 
key innovation: integrating the two networks during an on-line 
authorization transaction, and therefore being able to integrate the Internet 
authentication of the user and the authorization of the payment network 
into an single process that takes place during the on-line transaction. 
Because this integrated process can take place without the merchant 
needing to modify its existing payment protocol, it is accwately described 
in PDP claim 1 as "authenticating the payer and authorizing the proposed 
payment in a single integrated process conducted without the involvement 
of the merchant" 
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Thus, Barbara does not even remotely anticipate the improvements of 
PDP, which integrates the authentication and authorization process into a 
single integrated process, as described above, to create a unique payment 
service that improves the security and privacy of an online payment, while 
giving payers dynamic control over the online payment transaction after 
the merchant submits the payment to the payment network, all achieved 
within the constraints of the existing standard merchant payment process 
over the Internet. 

It is simply not the case, as stated in the Office Action, that "As per claim 

1, Barbara et al. discloses a method of making a payment, ... the 
improvement comprising the following act performed by a trusted third 
party service: authenticating the payer and authorizing the proposed 
payment in a single integrated process conducted without the involvement 
of the merchant." Barbara does not provide a means of authenticating the 
payer and authorizing the proposed payment in a single integrated process, 
let alone do so without the involvement of the merchant, as merchant 
modification of its payment system would be required to accept Barbara's 
transaction account. In addition, given these very fundamental differences 
between the design and operation of Barbara and PDP, a person of 
ordinary skill in the art would not be motivated by the information 
disclosed in Barbara to create the invention described in PDP claim 1, 

Accordingly, the Applicant respectfully requests that the Examiner 
withdraw the Office Action's rejection of claim 1, and allow that claim, 

2. Claim 2 was likewise rejected as being anticipated by Barbara, again 
citing the Abstract, Fig 1, and paragraph 21. 
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PDP claim 2 recites a method comprising "The improvement of claim 1 
further comprising the act of: 

a) allowing a persistent channel to be established between the trusted 
third party service and the payer prior to the payer completing the 
purchase, and wherein the act of authenticating the payer and 
authorizing the proposed payment in a single integrated process 
comprises the act of verifying that the persistent channel is available, 
and optionally contacting the payer over the persistent channel for 
additional authorization, if additional authorization is required by 
predetermined preferences." 

First, as covered at length above, Barbara does not anticipate PDP Claim 
1, from which claim 2 depends. Claim 2 incorporates all the elements of 
claim 1, and then adds a new element to the method of claim 1. Therefore, 
since, as demonstrated above, claim 1 is not anticipated by Barbara, it is 
impossible for claim 2 to be anticipated by Barbara. 

In addition, even assuming for the purpose of argument that claim 1 were 
anticipated, the additional elements incorporated by claim 2 are not 
present in Barbara. 

PDP Figures 3 and 9 show, from the process and technical perspectives, 
respectively, the creation of a persistent channel between the cardholder 
(customer) and the third party service (the PDPS) while the PDPS is 
connected to the payment network. This connection is maintained during 
the entire payment transaction and is in addition to the cardholder's 
connection to the merchant (recipient). 

In online transactions according to the instant invention, a payer 
authenticates to the PDPS over the persistent channel before a transaction 
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is completed with a merchant, and the transaction is validated using the 
persistent channel after the transaction is completed with the merchant 

This is very different from the service presented in Barbara, which does 
not mention any involvement with the online processing of the transaction 
during the authorization process with the merchant, while it passes 
through the payment network. Barbara receives the results of the 
authorization process from its partner financial institution, and apparently 
receives them only after the transaction is completed according to the 
partner's existing processes. 

The Office Action references the following paragraph in Barbara as 
support for its assertion: 

"[0021] In the on-line payment method and system for an embodiment of 
the present invention, the user can use the funds residing in the transaction 
account, for example, for making on-line payments, on-line purchases, 
off-line purchases, cash withdrawals, credit card account payments, bill 
payments, and/or international payments with funds in the transaction 
account. For an on-line payment, for example, funds in the transaction 
account are designated for the online payment to a recipient according to 
an instruction by the user. The user can make an on-line purchase, for 
example, by authorizing payment to an on-line merchant for an on-line 
transaction by furnishing the on-line merchant the transaction accoxmt 
number."' 

But Barbara's referenced process is completely different from PDP. For 
example, there is no requirement to be signed onto Barbara's service, or to 
remain signed on, when conducting an on-line purchase at a recipient 
(merchant), whereas PDP requires the persistent user authentication 
channel to be present to authorize a payment 
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Since authorization is the step that takes place after the payment is 
submitted at a merchant (Ic^ after the 'buy' button is pressed), it is not 
possible for Barbara to provide user control over authorization, as there is 
at that point no persistent channel connecting the user, the merchant, and 
the payment system. It is fimdamentally impossible for Barbara to 
perform the stated Amotion. Nor does anything in Barbara's also-cited 
Abstract or Fig. 1 suggests in any way the presence of such a persistent 
channel. 

Modifying Barbara to provide the persistent channel is antithetical to the 
original intent of Barbara, which is to leverage the Internet to facilitate and 
aggregate many types of payments on behalf of users bv leverajedng the 
existing processes of a financial institution partner, and such a 
modification would fimdamentally change Barbara from the way it was 
intended to be used. For the same reason, no person of ordinary skill in 
the art would be motivated by the information in Barbara to create the 
innovation described by PDP's claim 2. 

Accordingly, the Applicant respectfiilly requests that the Examiner 
withdraw the OfiEice Action's rejection of claim 2, and allow that claim. 

3. Claim 3 was likewise rejected as being anticipated by Barbara, citing 
the Abstract, paragraphs 21 and 93, and Figs 1-4. 

PDF claim 3 recites a method comprising "The improvement of claim 2 
fiirther comprising the acts of: 

a) receiving a request from a Payment Processor for approval of the 
proposed payment pertaining to the account number, whereby the 
account number was submitted as the proposed payment for the 
purchase; and 
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b) transmitting an instruction to the Payment Processor which 
depends on whether the transaction is verified or denied." 

First, as covered at length above, Barbara does not anticipate PDP Claims 
I or 2, from which claim 3 depends. Claim 3 incorporates all the elements 
of claim 2, and then adds new elements to the method of claim 2. 
Therefore, since, as demonstrated above, claims 1 and 2 are not 
anticipated by Barbara, or even if only claim 2 is not, then it is impossible 
for claim 3 to be anticipated by Barbara. 

In addition, even assximing for the purpose of argument that claims 1 and 2 
were both anticipated, the additional elements incorporated by claim 3 are 
not present in Barbara. 

PDP, page 7, lines 13-17, defines a Payment Processor as follows: "... a 
financial institution which is part of the inter-bank payment network and 
serves as the PDPS's gateway to the payment network. The Payment 
Processor is typically a bank, or an association such as VISA or 
MasterCard. The PDPS may be fiilly integrated with the Payment 
Processor or external with a secure communications link or partially 
integrated." 

The PDP application explains the process stated in claim 3 in great detail. 
A summary of how the PDPS approves the payment with the cardholder is 
found in the description of Figure 3, at page 34, line 20: 

"The Payment Processor obtains the actual card number fi-om PDPS 
(shown together as block 122) The PDPS attempts to validate the 
transaction based on the preferences specified by the cardholder during 
enrollment or as changed at some later date. The preferences can comprise 
automatic approval or automatic rejection based on preset criteria. 
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checking that the persistent channel is available, prompting for real time 
approval on the persistent channel, or contactit^ by telephone at a 
predetermined number. As previously noted, the cardholder may specify 
changes to other fields, such as transaction description, either by 
preference settings or during real time contact through the persistent 
channel. If approved the PDPS rewrites the authorization request with the 
valid accoimt number, billing address, and any revised description of 
merchandise and returns it to the Payment Processor." 

The Office Action references Barbara paragraph [0021], which was 
discussed above, as well as the following paragraph in Barbara to support 
its conclusions: 

"[0093] In addition, the system for an embodiment of the present 
invention, for example, ensures that all transaction data is maintained, 
generates various reports for settlement, including a new transactions 
report that details each new transaction initiated through the payment 
processor and a new transactions summary that is a summary of the 
information in the new transactions report, tracks senders' transactions and 
dollar amounts against their limits and country specific limits, halts a 
sender's ability to transact if the sender exceed limits, and accepts 
adjustments from customer service/operational areas to the sender's clip or 
transaction account 22 and transaction history log 106." 

But Barbara's referenced process, involving generating reports fi'om the 
Payment Processor after the on-line transaction has completed, is very 
different from PDP's on-line, real-time, processing of payment 
transactions. PDP completes its standard processing within the 
approximately 10-20 seconds that elapses between a consumer hitting the 
"buy" button on the merchant's web site, and the issuing bank approving 
the authorization request from the merchant. Barbara's reUance on 
existing bank processing, on the other hand, leads to a non-real-time, batch 
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environment. Barbara paragraph [0092] explains the context of referenced 
paragraph [0093] as follows: 

"[0092] . . . , the system for an embodiment of the present invention, for 
example, accepts international payment orders from the web site 78, 
creates a daily file of transaction detail orders, and transmits the orders to 
IMPS 100 and WorldLink 98". 

Barbara teaches batching of transactions and submitting the batch of 
transactions to the financial institution's system for later processing. 
Unlike PDP, Barbara does not directly participate in the authorization of 
payment transactions over the payment network, but merely interfaces 
with external systems of the financial institution partner. 

Barbara's method is composed of many separate steps and does not 
provide any teaching on how authentication and authorization can both be 
carried out in a single integrated process, let alone a single integrated 
process that occurs in real time, while the user remains connected to both 
the merchant and the PDP Service. Nothing in the cited paragraphs. 
Abstract, or Figs. 1-4 shows any such capability. 

Thus, Barbara does not in fact anticipate PDP Claim 3. And, as in the 
prior claims, the systems are so fimdamentally different that no person of 
ordinary skill in the art would be motivated by reading Barbara to create 
the innovation of PDP's claim 3, 

Accordingly, the Applicant respectfiilly requests tiiat the Examiner 
withdraw the Office Action's rejection of claim 3, and allow that claim. 

4. Claim 4 was likewise rejected as being anticipated by Barbara, again 
citing the Abstract and Fig. 1 . 
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PDP claim 4 recites a method comprising *'The improvement of claim 3 
wherein the trusted third party service comprises a portal accessible on a 
network through which the persistent channel may be established using a 
network accessible device". 

First, as covered at length above, Barbara does not anticipate PDP Claims 
1, 2, or 3, from which claim 4 depends. Claim 4 incorporates all the 
elements of claim 3, and then adds new elements to the method of claim 3. 
Therefore, since, as demonstrated above, claims 1, 2, and 3 are not 
anticipated by Barbara, or even if only claim 3 is not, then it is impossible 
for claim 4 to be anticipated by Barbara. 

In addition, even assuming for the purpose of argument that claims 1, 2, 
and 3 were anticipated, the additional elements incorporated by claim 4 
are not present in Barbara. 

While it is true that Barbara describes a portal-like service on the Internet, 
as discussed above, Barbara does not describe the creation of a persistent 
channel, which, as defined in PDP, is an on-line connection that exists 
between the Payment Processor and the cardholder that exists during the 
on-line authorization of a payment transaction over a payment network, in 
addition to the connection the cardholder has with the merchant. As stated 
in the PDP Summary of Invention, at page 8, line 5 — 6, "A persistent 
channel is a two way electronic communication with the PDPS, which is 
different from the channel used to communicate with the merchant'' 

Barbara's Abstract, referenced in the Office Action, provides no teaching 
related to a persistent channel. 
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Figure 1, also referenced in the Office Action, clearly shows a single 
connection between the customer and the Internet. PDP Figures 4 and 9, 
by contrast, show that during the authorization process the cardholders' 
browser maintains two separate connections, one with the merchant and 
the second with the PDP portal, which in turn is connected with the 
Payment Processor. Barbara does not disclose anything related to PDP's 
innovation of the persistent channel connecting the customer and the 
Payment Processor, via the PDP portal, at the same time the customer is 
connected to the merchant. 

Thus, Barbara does not in fact anticipate PDP Claim 4, nor, with the 
fundamentally different design and operation of the two systems, and no 
hint of PDP's persistent channel to be found in Barbara, would a person of 
ordinary skill in the art be motivated by Barbara to create the invention of 
PDP claim 4. 

Accordingly, the Applicant respectfully requests that the Examiner 
withdraw the Office Action's rejection of claim 4, and allow that claim. 

5. Claim 5 was rejected as being anticipated by Barbara, citing paragraph 
55. 

PDP claim 5 recites a method comprising "The improvement of claim 4 
wherein the trusted third party service further comprises a telephone 
connection through which the persistent channel may be established". 

First, as covered at length above, Barbara does not anticipate PDP Claims 
1, 2, or 3, or 4, from which claim 5 depends. Claim 5 incorporates all the 
elements of claim 4, and then adds new elements to the method of claim 4. 
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Therefore, since, as demonstrated above, claims 1, 2, 3, and 4 are not 
anticipated by Barbara, or even if only claim 4 is not, then it is impossible 
for claim 5 to be anticipated by Barbara. 

In addition, even assuming for the purpose of argument that claims 1, 2, 3, 
and 4 were anticipated, the additional elements incorporated by claim 5 
are not present in Barbara. 

The referenced Barbara paragraph [0055] reads as follows: 

"[0055] FIG, 4 is a flow chart which shows an example of the process of 

receiving a person-to-person payment for an embodiment of the present 

invention If the recipient 14 does not want to enroll in the system, at S 

19, the recipient 14 is provided, for example, with a 1-800 telephone 
number to call and request a check 38 from the system." 

Providing a user a telephone nimiber, so that the user can later call and 
request a manual check, bears no relation to PDP's systematically 
establishing a persistent channel with a cardholder via his or her telephone 
to authorize an online payment, while the cardholder is currently making 
an Intemet purchase at an on-line merchant. Barbara makes no other 
relevant reference to the use of a telephone. Nothing in the cited 
paragraph from Barbara describes or suggests PDP's system "wherein the 
trusted third party service further comprises a telephone connection 
through which the persistent channel may be established.'' 

PDP's embodiment making use of a telephone connection is explained on 
page 37, lines 15-18, and shown in Figure 5, as follows: "Another method 
would be to authenticate a user over the telephone and then keep the 
telephone line connection open as the persistent channel during the 
transaction. A telephone persistent channel is shown in process 142 on 
Figure 5" 
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Contrary to the Office Action, Barbara does not describe or suggest the 
creation of a persistent channel comprising a telephone connection, as set 
forth in PDP claim 5, and does not anticipate that claim, nor does it render 
it obvious, given the fundamentally different modes of operation of the 
two systems, regarding the purpose and use of a telephone connection. 

Accordingly, the Applicant respectfully requests that the Examiner 
withdraw the Office Action's rejection of claim 4, and allow that claim. 

6. Claim 6 was rejected as being anticipated by Barbara, citing the 
Abstract and Fig. 1. 

PDP claim 6 recites a method comprising "The improvement of claim 5 
wherein the transaction is an e-commerce transaction on the network, and 
wherein the transaction takes place between the payer's network 
accessible device and the merchant's world wide web site on the 
network." 

First, as covered at length above, Barbara does not anticipate PDP Claims 
1, 2, 3, 4, or 5, from which claim 6 depends. Claim 6 incorporates all the 
elements of claim 5, and then adds new elements to the method of claim 5. 
Therefore, since, as demonstrated above, claims 1, 2, 3, 4, and 5 are not 
anticipated by Barbara, or even if only claim 5 is not, then it is impossible 
for claim 6 to be anticipated by Barbara. 

In addition, even assuming for the purpose of argument that claims 1, 2, 3, 
4, and 5 were all anticipated, the additional elements incorporated by 
claim 6 are not present in Barbara. 
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The Office Action references Barbara's Abstract, as well as Figure 1, in 
support of its assertion. While this material describes a form of 
generalized e-commerce transaction, it in no way discloses a system 
capable of the types of flexible, secure transactions permitted by the novel 
features of PDP, utilized as described in claim 6. 

Network accessible devices are described in the PDP Description of the 
Preferred Embodiments, at page 20, lines 3-13, as follows: "Transactions 
are made using network accessible devices, which comprise computing 
devices such as computer systems. Personal Digital Assistants, network 
enabled wireless telephones, set top boxes, and special purpose network 
accessible devices. Network accessible devices comprise devices operated 
directly by persons, devices that are preprogranmied by software 
executing thereon, or which are operated by other physical devices. 
Network accessible devices are distinguished from ordinary telephones 
communicating over a telephone network. It will be appreciated by those 
skilled in the art that the type of transactions being discussed herein need 
not be carried out directly by a human user but may be carried out by a 
network connected automated software appUcation, or software operated 
hardware device." 

Barbara consistently refers to the operator of the system as a "user," ije., 
an online consumer Barbara in no way anticipates a more complex 
environment as stated above, where for example, a user could be a 
software agent as opposed to a human. 

Barbara does not in fact anticipate PDP Claim 6, nor would a person of 
ordinary skill in the art be motivated by Barbara to create the innovation 
of PDP's claim 6. 
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Accordingly, the Applicant respectfully requests that the Examiner 
withdraw the Office Action's rejection of claim 6, and allow that claim. 

7. Claim 7 was rejected as being disclosed by Barbara, citing Paragraph 
2L 

PDP claim 7 recites a method comprising "The improvement of claim 5 
wherein the purchase involves personal contact between the payer and the 
merchant" 

First, as covered at length above, Barbara does not anticipate PDP Claims 
1 , 2, 3, 4, or 5, from which claim 7 depends. Claim 7 incorporates all the 
elements of claim 5, and then adds new elements to the method of claim 5. 
Therefore, since, as demonstrated above, claims 1, 2, 3, 4, and 5 are not 
anticipated by Barbara, or even if only claim 5 is not, then it is impossible 
for claim 7 to be anticipated by Barbara. 

In addition, even assuming for the purpose of argument that claims 1, 2, 3, 
4, and 5 were all anticipated, the additional element incorporated by claim 
7 is not present in Barbara. 

The Office Action references Barbara paragraph [0021] to support its 
assertion: 

"[002 1 ] . . . .The user can also make an off-line purchase bv authorizing 
payment to an off-line bricks and mortar merchant using a transaction card 
provided to the user in connection with the transaction account. 
Alternatively, the user can withdraw funds in cash from the transaction 
account at a self-service financial transaction terminal with the transaction 
card." 
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While a physical purchase card, if desired, can be provided in both 
Barbara and PDP, the way any card transactions are processed is very 
different. In Barbara the transactions would be processed through its 
financial intermediary partner using their existing processes, as described 
in cited paragraph 21, above. 

The use of such a card in PDP is described starting at page 37, line 7 of the 
written description, and on Figure 5: "The credit card can also be used 
with an in person transaction at the merchant's store, as shown in process 
105 on Figure 5. There are a number of options which can implemented 
in this case. . . . Another method would be to authenticate a user over the 
telephone and then keep the telephone line connection open as the 
persistent channel during the transaction. A telephone persistent channel 
is shown in process 142 on Figure 5." 



Figure 5 describes a very different purchase process from Barbara, since 
the persistent channel is created between the user's telephone and the PDP 
connected to the payment network (142). Before the purchase is approved 
the PDP verifies that the persistent channel is present, and assuming it is, 
the online authorization transaction is competed back to the merchant 
(110). 



Barbara allows users to register a credit card account as a source account 
for the transaction account, and insulates users from utilizing their credit 
card number by allowing users to provide recipients their transaction 
accoimt number instead. In [0061] Barbara also discusses issuing their 
users a physical credit card so that payments could be conducted in the 
real world. In this case, however, since the physical card uses the standard 
credit card number syntax, the transaction is processed just like any 
standard credit card transaction, and without PDP's improvements of a 
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single integrated authorization and authentication process, persistent 
mediation, etc. 

So, Barbara does not describe or suggest that during a purchase from an 
"off-line bricks and mortar merchant/' a persistent channel is created to 
authenticate and authorize the purchase, as is the case in PDP claim 7. 

Barbara therefore does not anticipate claim 7, nor would a person of 
ordinary skill in the art be motivated by Barbara to create the aspect of 
PDP that is set forth in claim 7. 

Accordingly, the Applicant respectfully requests that the Examiner 
withdraw the Office Action's rejection of claim 7, and alJow that claim. 

8. Claim 8 was rejected as being anticipated by Barbara, citing Paragraphs 
58, 61, and 93. 

PDP claim 8 recites a method comprising "The improvement of claim 6 or 
claim 7 wherein the Payment Processor is the issuer of a payment card 
accoimt having the account number." 

First, as covered at length above, Barbara does not anticipate PDP Claims 
1, 2, 3, 4, 5, 6, or 7, from which claim 8 depends. Claim 8 incorporates all 
the elements of claim 6 or claim 7, and then adds new elements to the 
methods of those claims. Therefore, since, as demonstrated above, claims 
1 , 2, 3, 4, 5, 6, and 7 are not anticipated by Barbara, or even if only claims 
6 and 7 are not, then it is impossible for claim 8 to be anticipated by 
Barbara. 
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In addition, even assuming for the purpose of argument that claims 1, 2, 3, 
4, 5, 6, and 7 were all anticipated, the additional elements incorporated by 
claim 8 are not present in Barbara. 

Claim 8 introduces an ahemative that impacts which physical entity 
processes which portion of the method. See PDP page 13, line 10: "In one 
attractive embodiment, the proxy account nimiber is also a valid account 
number of an actual account, when the actual accoimt is issued by the 
Payment Processor (te^ the issuing bank is the Payment Processor).'* 
Comparing Figure 4, where the PDPS is a separate entity, with Figure 5, 
where the issuing bank assumes the role of the PDPS, shows that one step 
is eliminated in this option because the issuing bank and the Payment 
Processor coincide. 

The Office Action references Barbara paragraph [0058], [0061] and 
[0093]. While Barbara does mention issuing a physical credit card, the 
method in which the credit card is authenticated and authorized is 
completely different - it is still the same multi-step process, leveraging the 
same processes of the partner financial institution, as discussed above with 
respect to earlier claims, as opposed to the integrated authorization and 
authentication process afforded by the PDPS. Barbara also does not 
envision the streamlined process that eliminates a step when the issuing 
bank and the Payment Processor coincide. Nothing in the cited paragraphs 
is to the contrary. 

Barbara therefore does not anticipate claim 8, nor does Barbara provide 
information, which would motivate a person of ordinary skill in the art to 
create the innovation of PDP claim 8. 

Accordingly, the Applicant respectfully requests that the Examiner 
withdraw the Office Action's rejection of claim 8, and allow that claim. 
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9. Claim 9 was rejected as being anticipated by Barbara, citing Paragraphs 
55, 98, and 101. 

PDP claim 9 recites a method comprising "the improvement of claim 6 
wherein the trusted third party service comprises an instant message 
system and the persistent channel is established over the instant message 
system." 

First, as covered at length above, Barbara does not anticipate PDP Claims 
1, 2, 3, 4, 5, or 6, from which claim 8 depends. Claim 8 incorporates all 
the elements of claim 6, and then adds new elements to the method of that 
claim. Therefore, since, as demonstrated above, claims 1, 2, 3, 4, 5, and 6 
are not anticipated by Barbara, or even if only claim 6 is not, then it is 
impossible for claim 8 to be anticipated by Barbara. 

In addition, even assuming for the purpose of argument that claims 1, 2, 3, 
4, 5, and 6 were all anticipated, the additional elements incorporated by 
claim 9 are not present in Barbara. 

The Office Action references Barbara paragraph [0055], [0061] and 
[0103] in support of its assertions. 

"[0055] FIG. 4 is a flow chart which shows an example of the process of 
receiving a person-to-person payment for an embodiment of the present 
invention. Referring to FIG. 4, while the recipient 14 is browsing through 
the recipient's e-mail, for example, at SI 7, the recipient 14 discovers that 
he or she has an e-mail message advising that the recipient 14 has received 
the funds. At SI 8, the recipient 14 is asked to register to the service of the 
present invention to receive the fimds. If the recipient 14 does not want to 
enroll in the system, at S 19, the recipient 14 is provided, for example. 
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with a 1-800 telephone number to call and request a check 38 from the 
system ..." 

"[0098] In a user interface aspect for an embodiment of the present 
invention, for example, labels are hyperlinked with pop up windows that 
explain the field with additional context help as appropriate. Javascript is 
used for real time validation of all required fields. Information collected 
from the customer 10 or 14 is displayed on edit/confirm pages. The 
customer 10 or 14 is allowed to edit the information necessary, and data 
entry is simplified. Error messages are generated by an Intemet layer, 
based on requirements of fields and tables. These messages are specific 
and user-friendly. User information for each session is cached on the 
Intemet level to facilitate additional flexibility in both display and capture 
of information, as well as greater speed" 

"[0103] Additional features of the user interface for an embodiment of the 
present invention include, for example, secure messaging , a point of entry 
into the system, and branding. New registrations enter the system of the 
present invention via a variety of customized flows. Existing customers 
have a specific logon page which has the abilitv to have marketing notices 
posted to the customer . ..." 

These references mention Barbara* s use of email, and the ability to display 
error messages to the user. It is not clear what Barbara means by secure 
messaging as it is not mentioned anywhere else in the document. It is 
reasonable to conclude, however, that this relates to the use of a secure 
email approach, as email is mentioned elsewhere in the document. In any 
event, Barbara does not teach the use of an instant message system, let 
alone the use of an instant messaging system as a persistent channel to 
authenticate and authorize a purchase transaction in a single integrated 
process without participation by the merchant, as PDP does. 
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PDP Figure 12B shows how the instant message system is utilized as a 
persistent channel (207 and 204) in PDP. It is important to note that an 
online authorization method cannot be conducted with one part being 
based on an email message to a participant in the process. Online 
authorization takes place within seconds, and only an instant message, 
which is instantly displayed, could be utilized in PDP. 

Contrary to the Office Action, Barbara does not describe 'the 
improvement of claim 6 wherein the trusted third party service comprises 
an instant message system and the persistent channel is established over 
the instant message system". In fact, Barbara's teaching of an email 
system runs counter to PDP's use of a persistent channel while the 
transaction is taking place, and especially to utilizing instant messaging to 
establish such a real-time persistent channel. 

Barbara therefore does not anticipate claim 9. Nor would a person of 
ordinary skill in the art be motivated to create a system like PDP, 
including the innovation described by claim 9, based upon the information 
in Barbara. 

Accordingly, the Applicant respectfully requests that the Examiner 
withdraw the Office Action's rejection of claim 9, and allow that claim. 

Conclusion 

Barbara simply does not disclose what the Office Action says it does, with 
respect to claims 1 -9 of this application. As discussed at length above, 
Barbara does not anticipate PDP claims 1-9. Nor does Barbara provide 



28 



information from which a person of ordinary skill in the art would be led 
to create the invention circumscribed by those claims. 

Accordingly, the Applicant respectfully requests that the Examiner 
withdraw the Office Action's rejection of Claims 1-9, and allow those 
claims. 

Claims 10-60 are withdrawn from consideration. A revised set of claims 
reflecting this withdrawal is attached. 

Applicant believes that claims 1- 9 of the present application are now in 
condition for allowance, and respectfully requests that the application be 
passed to allowance. 

Please contact the undersigned attomey at (408) 293-0880 to discuss any 
aspect of this case. 

Respectfully submitted. 

Barton A. Smith 
Registration No. 50,763 
Attomey for Applicant 
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